Add Simplified Chinese localization to the admin panel - #981

Thanks a lot for this contribution, it's a big and careful piece of work!

Verification

• Azure Pipelines failure is not caused by this PR. The MUnique.OpenMU check fails instantly (start == end) on other PRs too, including already merged ones (#973, #977, #978), so it's an infrastructure issue on our side.
• I built the PR head and a test merge onto the current master (866b0f55, merges without conflicts) on Linux with .NET 10: dotnet build -c Release -p:ci=true → 0 errors.
• All test projects pass (Tests 1033, Web.Tests 116, PlugIns 41, Network.Packets 602, Persistence.Initialization, AttributeSystem, ChatServer, Network, Pathfinding).

Looks good

• ModelResourceProvider.GetModelResourceString walks base types, which fixes captions for the persistence-generated derived model types.
• Switching the culture selector and RequestLocalizationOptions to culture.Name is needed for zh-CN. Existing de/en values still resolve, because neutral cultures keep the same name.
• LocalizedPaginator subscribes to and unsubscribes from PaginationState correctly.
• FieldCaption and EnumSelect now use DisplayAttribute.GetName(), which respects ResourceType.

Before merging

1. TranslationCoverageTests.ChineseResourceSetsMatchNeutralKeysAndPlaceholders makes zh-CN mandatory for every new string. Every future PR that adds a key to one of the 12 neutral resource sets would fail CI unless it also adds a Chinese translation. No other language (e.g. de) has this requirement. Most contributors can't provide Chinese, so this would block unrelated work. Please keep the placeholder-consistency check (it's valuable), but only for keys that exist in zh-CN, and treat missing keys as fallback to English rather than a failure.

2. Numbered resource keys like BotConfiguration_Display1_Name … _Display13_Name (about 55 in GameLogic/Properties/PlugInResources.resx, 5 in Persistence.Initialization) have no link to the property they describe. Reordering or inserting a property silently makes the keys misleading, and reviewers can't see from the key what text it holds. Please name them after the member, e.g. BotConfiguration_ResetBots_Name / _Description, the same way ModelResources already does ({Type}_{Property}_Caption).

Minor (non-blocking)

• Update plugins (e.g. AddDuelConfigurationPlugIn) still keep PlugInName / PlugInDescription constants for the Name / Description overrides, while the [Display] text now lives in the resx. The English text is duplicated and can drift. Consider using the resource for both, or leaving the constants as the single source.
• PlugInPointCaption uses the English name/description text itself as the resx key. Editing the text of a plug-in point attribute silently drops its translation. That's acceptable as a fallback, but worth a comment in the class.
• Several ToString() overrides in DataModel are now culture-dependent. They also show up in server logs, so a server running under a non-English UI culture will log localized text. Probably fine, just be aware.

Happy to merge once 1 and 2 are addressed. 🙂

Generated by Claude Code

Thanks for the quick follow-up, @Qinjianbo! Re-review of dd99166f:

Both pre-merge points are resolved

1. ExistingChineseResourcesMatchNeutralPlaceholders now checks placeholders only for keys that have a Chinese translation and skips missing ones. The new MissingChineseKeyFallsBackToEnglish test with FallbackResources covers the fallback. Future PRs no longer need to add zh-CN text.
2. No numbered _DisplayN_ keys are left. All keys now follow {Type}_{Member}_Name/Description.

The minor points were also handled: the key behavior is documented in PlugInPointCaption.

Merge resolution (855e1734): I checked it with a remerge diff. Both sides of the resource conflicts were kept, including the upstream Raklion, guild-role and guild-page keys, and PartyBadge now uses upstream's PartyBadgeTitle. Nothing was lost.

Verification: I test-merged onto the current master (4348ecae) with no conflicts. On .NET 10:

• dotnet build -c Release -p:ci=true: 0 errors.
• All test projects pass: Tests 1120, Web.Tests 150, Network.Packets 608, Persistence.Initialization 32 (6 skipped), Network 73 (4 skipped), PlugIns 41, AttributeSystem 44, ChatServer 26, Pathfinding 10.

The failing Azure MUnique.OpenMU check is our infrastructure issue. It also fails instantly on other PRs, including merged ones, so it isn't caused by this PR. Codacy is green.

LGTM, merging. 🎉

Generated by Claude Code